| Junio C Hamano | 6f8a790 | 2006-05-22 01:10:13 | [diff] [blame] | 1 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" |
| 2 | "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> |
| 3 | <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> |
| 4 | <head> |
| 5 | <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> |
| 6 | <meta name="generator" content="AsciiDoc 7.0.2" /> |
| 7 | <style type="text/css"> |
| 8 | /* Debug borders */ |
| 9 | p, li, dt, dd, div, pre, h1, h2, h3, h4, h5, h6 { |
| 10 | /* |
| 11 | border: 1px solid red; |
| 12 | */ |
| 13 | } |
| 14 | |
| 15 | body { |
| 16 | margin: 1em 5% 1em 5%; |
| 17 | } |
| 18 | |
| 19 | a { color: blue; } |
| 20 | a:visited { color: fuchsia; } |
| 21 | |
| 22 | em { |
| 23 | font-style: italic; |
| 24 | } |
| 25 | |
| 26 | strong { |
| 27 | font-weight: bold; |
| 28 | } |
| 29 | |
| 30 | tt { |
| 31 | color: navy; |
| 32 | } |
| 33 | |
| 34 | h1, h2, h3, h4, h5, h6 { |
| 35 | color: #527bbd; |
| 36 | font-family: sans-serif; |
| 37 | margin-top: 1.2em; |
| 38 | margin-bottom: 0.5em; |
| 39 | line-height: 1.3; |
| 40 | } |
| 41 | |
| 42 | h1 { |
| 43 | border-bottom: 2px solid silver; |
| 44 | } |
| 45 | h2 { |
| 46 | border-bottom: 2px solid silver; |
| 47 | padding-top: 0.5em; |
| 48 | } |
| 49 | |
| 50 | div.sectionbody { |
| 51 | font-family: serif; |
| 52 | margin-left: 0; |
| 53 | } |
| 54 | |
| 55 | hr { |
| 56 | border: 1px solid silver; |
| 57 | } |
| 58 | |
| 59 | p { |
| 60 | margin-top: 0.5em; |
| 61 | margin-bottom: 0.5em; |
| 62 | } |
| 63 | |
| 64 | pre { |
| 65 | padding: 0; |
| 66 | margin: 0; |
| 67 | } |
| 68 | |
| 69 | span#author { |
| 70 | color: #527bbd; |
| 71 | font-family: sans-serif; |
| 72 | font-weight: bold; |
| 73 | font-size: 1.2em; |
| 74 | } |
| 75 | span#email { |
| 76 | } |
| 77 | span#revision { |
| 78 | font-family: sans-serif; |
| 79 | } |
| 80 | |
| 81 | div#footer { |
| 82 | font-family: sans-serif; |
| 83 | font-size: small; |
| 84 | border-top: 2px solid silver; |
| 85 | padding-top: 0.5em; |
| 86 | margin-top: 4.0em; |
| 87 | } |
| 88 | div#footer-text { |
| 89 | float: left; |
| 90 | padding-bottom: 0.5em; |
| 91 | } |
| 92 | div#footer-badges { |
| 93 | float: right; |
| 94 | padding-bottom: 0.5em; |
| 95 | } |
| 96 | |
| 97 | div#preamble, |
| 98 | div.tableblock, div.imageblock, div.exampleblock, div.verseblock, |
| 99 | div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock, |
| 100 | div.admonitionblock { |
| 101 | margin-right: 10%; |
| 102 | margin-top: 1.5em; |
| 103 | margin-bottom: 1.5em; |
| 104 | } |
| 105 | div.admonitionblock { |
| 106 | margin-top: 2.5em; |
| 107 | margin-bottom: 2.5em; |
| 108 | } |
| 109 | |
| 110 | div.content { /* Block element content. */ |
| 111 | padding: 0; |
| 112 | } |
| 113 | |
| 114 | /* Block element titles. */ |
| 115 | div.title, caption.title { |
| 116 | font-family: sans-serif; |
| 117 | font-weight: bold; |
| 118 | text-align: left; |
| 119 | margin-top: 1.0em; |
| 120 | margin-bottom: 0.5em; |
| 121 | } |
| 122 | div.title + * { |
| 123 | margin-top: 0; |
| 124 | } |
| 125 | |
| 126 | td div.title:first-child { |
| 127 | margin-top: 0.0em; |
| 128 | } |
| 129 | div.content div.title:first-child { |
| 130 | margin-top: 0.0em; |
| 131 | } |
| 132 | div.content + div.title { |
| 133 | margin-top: 0.0em; |
| 134 | } |
| 135 | |
| 136 | div.sidebarblock > div.content { |
| 137 | background: #ffffee; |
| 138 | border: 1px solid silver; |
| 139 | padding: 0.5em; |
| 140 | } |
| 141 | |
| 142 | div.listingblock > div.content { |
| 143 | border: 1px solid silver; |
| 144 | background: #f4f4f4; |
| 145 | padding: 0.5em; |
| 146 | } |
| 147 | |
| 148 | div.quoteblock > div.content { |
| 149 | padding-left: 2.0em; |
| 150 | } |
| 151 | div.quoteblock .attribution { |
| 152 | text-align: right; |
| 153 | } |
| 154 | |
| 155 | div.admonitionblock .icon { |
| 156 | vertical-align: top; |
| 157 | font-size: 1.1em; |
| 158 | font-weight: bold; |
| 159 | text-decoration: underline; |
| 160 | color: #527bbd; |
| 161 | padding-right: 0.5em; |
| 162 | } |
| 163 | div.admonitionblock td.content { |
| 164 | padding-left: 0.5em; |
| 165 | border-left: 2px solid silver; |
| 166 | } |
| 167 | |
| 168 | div.exampleblock > div.content { |
| 169 | border-left: 2px solid silver; |
| 170 | padding: 0.5em; |
| 171 | } |
| 172 | |
| 173 | div.verseblock div.content { |
| 174 | white-space: pre; |
| 175 | } |
| 176 | |
| 177 | div.imageblock div.content { padding-left: 0; } |
| 178 | div.imageblock img { border: 1px solid silver; } |
| 179 | span.image img { border-style: none; } |
| 180 | |
| 181 | dl { |
| 182 | margin-top: 0.8em; |
| 183 | margin-bottom: 0.8em; |
| 184 | } |
| 185 | dt { |
| 186 | margin-top: 0.5em; |
| 187 | margin-bottom: 0; |
| 188 | font-style: italic; |
| 189 | } |
| 190 | dd > *:first-child { |
| 191 | margin-top: 0; |
| 192 | } |
| 193 | |
| 194 | ul, ol { |
| 195 | list-style-position: outside; |
| 196 | } |
| 197 | ol.olist2 { |
| 198 | list-style-type: lower-alpha; |
| 199 | } |
| 200 | |
| 201 | div.tableblock > table { |
| 202 | border-color: #527bbd; |
| 203 | border-width: 3px; |
| 204 | } |
| 205 | thead { |
| 206 | font-family: sans-serif; |
| 207 | font-weight: bold; |
| 208 | } |
| 209 | tfoot { |
| 210 | font-weight: bold; |
| 211 | } |
| 212 | |
| 213 | div.hlist { |
| 214 | margin-top: 0.8em; |
| 215 | margin-bottom: 0.8em; |
| 216 | } |
| 217 | td.hlist1 { |
| 218 | vertical-align: top; |
| 219 | font-style: italic; |
| 220 | padding-right: 0.8em; |
| 221 | } |
| 222 | td.hlist2 { |
| 223 | vertical-align: top; |
| 224 | } |
| 225 | |
| 226 | @media print { |
| 227 | div#footer-badges { display: none; } |
| 228 | } |
| 229 | /* Workarounds for IE6's broken and incomplete CSS2. */ |
| 230 | |
| 231 | div.sidebar-content { |
| 232 | background: #ffffee; |
| 233 | border: 1px solid silver; |
| 234 | padding: 0.5em; |
| 235 | } |
| 236 | div.sidebar-title, div.image-title { |
| 237 | font-family: sans-serif; |
| 238 | font-weight: bold; |
| 239 | margin-top: 0.0em; |
| 240 | margin-bottom: 0.5em; |
| 241 | } |
| 242 | |
| 243 | div.listingblock div.content { |
| 244 | border: 1px solid silver; |
| 245 | background: #f4f4f4; |
| 246 | padding: 0.5em; |
| 247 | } |
| 248 | |
| 249 | div.quoteblock-content { |
| 250 | padding-left: 2.0em; |
| 251 | } |
| 252 | |
| 253 | div.exampleblock-content { |
| 254 | border-left: 2px solid silver; |
| 255 | padding-left: 0.5em; |
| 256 | } |
| 257 | </style> |
| 258 | <title>A tutorial introduction to git: part two</title> |
| 259 | </head> |
| 260 | <body> |
| 261 | <div id="header"> |
| 262 | <h1>A tutorial introduction to git: part two</h1> |
| 263 | </div> |
| 264 | <div id="preamble"> |
| 265 | <div class="sectionbody"> |
| 266 | <p>You should work through <a href="tutorial.html">A tutorial introduction to |
| 267 | git</a> before reading this tutorial.</p> |
| 268 | <p>The goal of this tutorial is to introduce two fundamental pieces of |
| 269 | git's architecture—the object database and the index file—and to |
| 270 | provide the reader with everything necessary to understand the rest |
| 271 | of the git documentation.</p> |
| 272 | </div> |
| 273 | </div> |
| 274 | <h2>The git object database</h2> |
| 275 | <div class="sectionbody"> |
| 276 | <p>Let's start a new project and create a small amount of history:</p> |
| 277 | <div class="listingblock"> |
| 278 | <div class="content"> |
| 279 | <pre><tt>$ mkdir test-project |
| 280 | $ cd test-project |
| 281 | $ git init-db |
| 282 | defaulting to local storage area |
| 283 | $ echo 'hello world' > file.txt |
| 284 | $ git add . |
| 285 | $ git commit -a -m "initial commit" |
| 286 | Committing initial tree 92b8b694ffb1675e5975148e1121810081dbdffe |
| 287 | $ echo 'hello world!' >file.txt |
| 288 | $ git commit -a -m "add emphasis"</tt></pre> |
| 289 | </div></div> |
| 290 | <p>What are the 40 digits of hex that git responded to the first commit |
| 291 | with?</p> |
| 292 | <p>We saw in part one of the tutorial that commits have names like this. |
| 293 | It turns out that every object in the git history is stored under |
| 294 | such a 40-digit hex name. That name is the SHA1 hash of the object's |
| 295 | contents; among other things, this ensures that git will never store |
| 296 | the same data twice (since identical data is given an identical SHA1 |
| 297 | name), and that the contents of a git object will never change (since |
| 298 | that would change the object's name as well).</p> |
| 299 | <p>We can ask git about this particular object with the cat-file |
| 300 | command—just cut-and-paste from the reply to the initial commit, to |
| 301 | save yourself typing all 40 hex digits:</p> |
| 302 | <div class="listingblock"> |
| 303 | <div class="content"> |
| 304 | <pre><tt>$ git cat-file -t 92b8b694ffb1675e5975148e1121810081dbdffe |
| 305 | tree</tt></pre> |
| 306 | </div></div> |
| 307 | <p>A tree can refer to one or more "blob" objects, each corresponding to |
| 308 | a file. In addition, a tree can also refer to other tree objects, |
| 309 | thus creating a directory heirarchy. You can examine the contents of |
| 310 | any tree using ls-tree (remember that a long enough initial portion |
| 311 | of the SHA1 will also work):</p> |
| 312 | <div class="listingblock"> |
| 313 | <div class="content"> |
| 314 | <pre><tt>$ git ls-tree 92b8b694 |
| 315 | 100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad file.txt</tt></pre> |
| 316 | </div></div> |
| 317 | <p>Thus we see that this tree has one file in it. The SHA1 hash is a |
| 318 | reference to that file's data:</p> |
| 319 | <div class="listingblock"> |
| 320 | <div class="content"> |
| 321 | <pre><tt>$ git cat-file -t 3b18e512 |
| 322 | blob</tt></pre> |
| 323 | </div></div> |
| 324 | <p>A "blob" is just file data, which we can also examine with cat-file:</p> |
| 325 | <div class="listingblock"> |
| 326 | <div class="content"> |
| 327 | <pre><tt>$ git cat-file blob 3b18e512 |
| 328 | hello world</tt></pre> |
| 329 | </div></div> |
| 330 | <p>Note that this is the old file data; so the object that git named in |
| 331 | its response to the initial tree was a tree with a snapshot of the |
| 332 | directory state that was recorded by the first commit.</p> |
| 333 | <p>All of these objects are stored under their SHA1 names inside the git |
| 334 | directory:</p> |
| 335 | <div class="listingblock"> |
| 336 | <div class="content"> |
| 337 | <pre><tt>$ find .git/objects/ |
| 338 | .git/objects/ |
| 339 | .git/objects/pack |
| 340 | .git/objects/info |
| 341 | .git/objects/3b |
| 342 | .git/objects/3b/18e512dba79e4c8300dd08aeb37f8e728b8dad |
| 343 | .git/objects/92 |
| 344 | .git/objects/92/b8b694ffb1675e5975148e1121810081dbdffe |
| 345 | .git/objects/54 |
| 346 | .git/objects/54/196cc2703dc165cbd373a65a4dcf22d50ae7f7 |
| 347 | .git/objects/a0 |
| 348 | .git/objects/a0/423896973644771497bdc03eb99d5281615b51 |
| 349 | .git/objects/d0 |
| 350 | .git/objects/d0/492b368b66bdabf2ac1fd8c92b39d3db916e59 |
| 351 | .git/objects/c4 |
| 352 | .git/objects/c4/d59f390b9cfd4318117afde11d601c1085f241</tt></pre> |
| 353 | </div></div> |
| 354 | <p>and the contents of these files is just the compressed data plus a |
| 355 | header identifying their length and their type. The type is either a |
| 356 | blob, a tree, a commit, or a tag. We've seen a blob and a tree now, |
| 357 | so next we should look at a commit.</p> |
| 358 | <p>The simplest commit to find is the HEAD commit, which we can find |
| 359 | from .git/HEAD:</p> |
| 360 | <div class="listingblock"> |
| 361 | <div class="content"> |
| 362 | <pre><tt>$ cat .git/HEAD |
| 363 | ref: refs/heads/master</tt></pre> |
| 364 | </div></div> |
| 365 | <p>As you can see, this tells us which branch we're currently on, and it |
| 366 | tells us this by naming a file under the .git directory, which itself |
| 367 | contains a SHA1 name referring to a commit object, which we can |
| 368 | examine with cat-file:</p> |
| 369 | <div class="listingblock"> |
| 370 | <div class="content"> |
| 371 | <pre><tt>$ cat .git/refs/heads/master |
| 372 | c4d59f390b9cfd4318117afde11d601c1085f241 |
| 373 | $ git cat-file -t c4d59f39 |
| 374 | commit |
| 375 | $ git cat-file commit c4d59f39 |
| 376 | tree d0492b368b66bdabf2ac1fd8c92b39d3db916e59 |
| 377 | parent 54196cc2703dc165cbd373a65a4dcf22d50ae7f7 |
| 378 | author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143418702 -0500 |
| 379 | committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143418702 -0500 |
| 380 | |
| 381 | add emphasis</tt></pre> |
| 382 | </div></div> |
| 383 | <p>The "tree" object here refers to the new state of the tree:</p> |
| 384 | <div class="listingblock"> |
| 385 | <div class="content"> |
| 386 | <pre><tt>$ git ls-tree d0492b36 |
| 387 | 100644 blob a0423896973644771497bdc03eb99d5281615b51 file.txt |
| 388 | $ git cat-file commit a0423896 |
| 389 | hello world!</tt></pre> |
| 390 | </div></div> |
| 391 | <p>and the "parent" object refers to the previous commit:</p> |
| 392 | <div class="listingblock"> |
| 393 | <div class="content"> |
| 394 | <pre><tt>$ git-cat-file commit 54196cc2 |
| 395 | tree 92b8b694ffb1675e5975148e1121810081dbdffe |
| 396 | author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500 |
| 397 | committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500 |
| 398 | |
| 399 | initial commit</tt></pre> |
| 400 | </div></div> |
| 401 | <p>The tree object is the tree we examined first, and this commit is |
| 402 | unusual in that it lacks any parent.</p> |
| 403 | <p>Most commits have only one parent, but it is also common for a commit |
| 404 | to have multiple parents. In that case the commit represents a |
| 405 | merge, with the parent references pointing to the heads of the merged |
| 406 | branches.</p> |
| 407 | <p>Besides blobs, trees, and commits, the only remaining type of object |
| 408 | is a "tag", which we won't discuss here; refer to <a href="git-tag.html">git-tag(1)</a> |
| 409 | for details.</p> |
| 410 | <p>So now we know how git uses the object database to represent a |
| 411 | project's history:</p> |
| 412 | <ul> |
| 413 | <li> |
| 414 | <p> |
| 415 | "commit" objects refer to "tree" objects representing the |
| 416 | snapshot of a directory tree at a particular point in the |
| 417 | history, and refer to "parent" commits to show how they're |
| 418 | connected into the project history. |
| 419 | </p> |
| 420 | </li> |
| 421 | <li> |
| 422 | <p> |
| 423 | "tree" objects represent the state of a single directory, |
| 424 | associating directory names to "blob" objects containing file |
| 425 | data and "tree" objects containing subdirectory information. |
| 426 | </p> |
| 427 | </li> |
| 428 | <li> |
| 429 | <p> |
| 430 | "blob" objects contain file data without any other structure. |
| 431 | </p> |
| 432 | </li> |
| 433 | <li> |
| 434 | <p> |
| 435 | References to commit objects at the head of each branch are |
| 436 | stored in files under .git/refs/heads/. |
| 437 | </p> |
| 438 | </li> |
| 439 | <li> |
| 440 | <p> |
| 441 | The name of the current branch is stored in .git/HEAD. |
| 442 | </p> |
| 443 | </li> |
| 444 | </ul> |
| 445 | <p>Note, by the way, that lots of commands take a tree as an argument. |
| 446 | But as we can see above, a tree can be referred to in many different |
| 447 | ways—by the SHA1 name for that tree, by the name of a commit that |
| 448 | refers to the tree, by the name of a branch whose head refers to that |
| 449 | tree, etc.—and most such commands can accept any of these names.</p> |
| 450 | <p>In command synopses, the word "tree-ish" is sometimes used to |
| 451 | designate such an argument.</p> |
| 452 | </div> |
| 453 | <h2>The index file</h2> |
| 454 | <div class="sectionbody"> |
| 455 | <p>The primary tool we've been using to create commits is "git commit |
| 456 | -a", which creates a commit including every change you've made to |
| 457 | your working tree. But what if you want to commit changes only to |
| 458 | certain files? Or only certain changes to certain files?</p> |
| 459 | <p>If we look at the way commits are created under the cover, we'll see |
| 460 | that there are more flexible ways creating commits.</p> |
| 461 | <p>Continuing with our test-project, let's modify file.txt again:</p> |
| 462 | <div class="listingblock"> |
| 463 | <div class="content"> |
| 464 | <pre><tt>$ echo "hello world, again" >>file.txt</tt></pre> |
| 465 | </div></div> |
| 466 | <p>but this time instead of immediately making the commit, let's take an |
| 467 | intermediate step, and ask for diffs along the way to keep track of |
| 468 | what's happening:</p> |
| 469 | <div class="listingblock"> |
| 470 | <div class="content"> |
| 471 | <pre><tt>$ git diff |
| 472 | --- a/file.txt |
| 473 | +++ b/file.txt |
| 474 | @@ -1 +1,2 @@ |
| 475 | hello world! |
| 476 | +hello world, again |
| 477 | $ git update-index file.txt |
| 478 | $ git diff</tt></pre> |
| 479 | </div></div> |
| 480 | <p>The last diff is empty, but no new commits have been made, and the |
| 481 | head still doesn't contain the new line:</p> |
| 482 | <div class="listingblock"> |
| 483 | <div class="content"> |
| 484 | <pre><tt>$ git-diff HEAD |
| 485 | diff --git a/file.txt b/file.txt |
| 486 | index a042389..513feba 100644 |
| 487 | --- a/file.txt |
| 488 | +++ b/file.txt |
| 489 | @@ -1 +1,2 @@ |
| 490 | hello world! |
| 491 | +hello world, again</tt></pre> |
| 492 | </div></div> |
| 493 | <p>So "git diff" is comparing against something other than the head. |
| 494 | The thing that it's comparing against is actually the index file, |
| 495 | which is stored in .git/index in a binary format, but whose contents |
| 496 | we can examine with ls-files:</p> |
| 497 | <div class="listingblock"> |
| 498 | <div class="content"> |
| 499 | <pre><tt>$ git ls-files --stage |
| 500 | 100644 513feba2e53ebbd2532419ded848ba19de88ba00 0 file.txt |
| 501 | $ git cat-file -t 513feba2 |
| 502 | blob |
| 503 | $ git cat-file blob 513feba2 |
| 504 | hello world, again</tt></pre> |
| 505 | </div></div> |
| 506 | <p>So what our "git update-index" did was store a new blob and then put |
| 507 | a reference to it in the index file. If we modify the file again, |
| 508 | we'll see that the new modifications are reflected in the "git-diff" |
| 509 | output:</p> |
| 510 | <div class="listingblock"> |
| 511 | <div class="content"> |
| 512 | <pre><tt>$ echo 'again?' >>file.txt |
| 513 | $ git diff |
| 514 | index 513feba..ba3da7b 100644 |
| 515 | --- a/file.txt |
| 516 | +++ b/file.txt |
| 517 | @@ -1,2 +1,3 @@ |
| 518 | hello world! |
| 519 | hello world, again |
| 520 | +again?</tt></pre> |
| 521 | </div></div> |
| 522 | <p>With the right arguments, git diff can also show us the difference |
| 523 | between the working directory and the last commit, or between the |
| 524 | index and the last commit:</p> |
| 525 | <div class="listingblock"> |
| 526 | <div class="content"> |
| 527 | <pre><tt>$ git diff HEAD |
| 528 | diff --git a/file.txt b/file.txt |
| 529 | index a042389..ba3da7b 100644 |
| 530 | --- a/file.txt |
| 531 | +++ b/file.txt |
| 532 | @@ -1 +1,3 @@ |
| 533 | hello world! |
| 534 | +hello world, again |
| 535 | +again? |
| 536 | $ git diff --cached |
| 537 | diff --git a/file.txt b/file.txt |
| 538 | index a042389..513feba 100644 |
| 539 | --- a/file.txt |
| 540 | +++ b/file.txt |
| 541 | @@ -1 +1,2 @@ |
| 542 | hello world! |
| 543 | +hello world, again</tt></pre> |
| 544 | </div></div> |
| 545 | <p>At any time, we can create a new commit using "git commit" (without |
| 546 | the -a option), and verify that the state committed only includes the |
| 547 | changes stored in the index file, not the additional change that is |
| 548 | still only in our working tree:</p> |
| 549 | <div class="listingblock"> |
| 550 | <div class="content"> |
| 551 | <pre><tt>$ git commit -m "repeat" |
| 552 | $ git diff HEAD |
| 553 | diff --git a/file.txt b/file.txt |
| 554 | index 513feba..ba3da7b 100644 |
| 555 | --- a/file.txt |
| 556 | +++ b/file.txt |
| 557 | @@ -1,2 +1,3 @@ |
| 558 | hello world! |
| 559 | hello world, again |
| 560 | +again?</tt></pre> |
| 561 | </div></div> |
| 562 | <p>So by default "git commit" uses the index to create the commit, not |
| 563 | the working tree; the -a option to commit tells it to first update |
| 564 | the index with all changes in the working tree.</p> |
| 565 | <p>Finally, it's worth looking at the effect of "git add" on the index |
| 566 | file:</p> |
| 567 | <div class="listingblock"> |
| 568 | <div class="content"> |
| 569 | <pre><tt>$ echo "goodbye, world" >closing.txt |
| 570 | $ git add closing.txt</tt></pre> |
| 571 | </div></div> |
| 572 | <p>The effect of the "git add" was to add one entry to the index file:</p> |
| 573 | <div class="listingblock"> |
| 574 | <div class="content"> |
| 575 | <pre><tt>$ git ls-files --stage |
| 576 | 100644 8b9743b20d4b15be3955fc8d5cd2b09cd2336138 0 closing.txt |
| 577 | 100644 513feba2e53ebbd2532419ded848ba19de88ba00 0 file.txt</tt></pre> |
| 578 | </div></div> |
| 579 | <p>And, as you can see with cat-file, this new entry refers to the |
| 580 | current contents of the file:</p> |
| 581 | <div class="listingblock"> |
| 582 | <div class="content"> |
| 583 | <pre><tt>$ git cat-file blob a6b11f7a |
| 584 | goodbye, word</tt></pre> |
| 585 | </div></div> |
| 586 | <p>The "status" command is a useful way to get a quick summary of the |
| 587 | situation:</p> |
| 588 | <div class="listingblock"> |
| 589 | <div class="content"> |
| 590 | <pre><tt>$ git status |
| 591 | # |
| 592 | # Updated but not checked in: |
| 593 | # (will commit) |
| 594 | # |
| 595 | # new file: closing.txt |
| 596 | # |
| 597 | # |
| 598 | # Changed but not updated: |
| 599 | # (use git-update-index to mark for commit) |
| 600 | # |
| 601 | # modified: file.txt |
| 602 | #</tt></pre> |
| 603 | </div></div> |
| 604 | <p>Since the current state of closing.txt is cached in the index file, |
| 605 | it is listed as "updated but not checked in". Since file.txt has |
| 606 | changes in the working directory that aren't reflected in the index, |
| 607 | it is marked "changed but not updated". At this point, running "git |
| 608 | commit" would create a commit that added closing.txt (with its new |
| 609 | contents), but that didn't modify file.txt.</p> |
| 610 | <p>Also, note that a bare "git diff" shows the changes to file.txt, but |
| 611 | not the addition of closing.txt, because the version of closing.txt |
| 612 | in the index file is identical to the one in the working directory.</p> |
| 613 | <p>In addition to being the staging area for new commits, the index file |
| 614 | is also populated from the object database when checking out a |
| 615 | branch, and is used to hold the trees involved in a merge operation. |
| 616 | See the <a href="core-tutorial.txt">core tutorial</a> and the relevant man |
| 617 | pages for details.</p> |
| 618 | </div> |
| 619 | <h2>What next?</h2> |
| 620 | <div class="sectionbody"> |
| 621 | <p>At this point you should know everything necessary to read the man |
| 622 | pages for any of the git commands; one good place to start would be |
| Junio C Hamano | 59929ee | 2006-05-22 22:34:54 | [diff] [blame] | 623 | with the commands mentioned in <a href="everyday.html">Everyday git</a>. You |
| Junio C Hamano | 6f8a790 | 2006-05-22 01:10:13 | [diff] [blame] | 624 | should be able to find any unknown jargon in the |
| Junio C Hamano | bb8fb05 | 2006-05-30 07:21:12 | [diff] [blame^] | 625 | <a href="glossary.html">Glossary</a>.</p> |
| Junio C Hamano | 6f8a790 | 2006-05-22 01:10:13 | [diff] [blame] | 626 | <p>The <a href="cvs-migration.html">CVS migration</a> document explains how to |
| 627 | import a CVS repository into git, and shows how to use git in a |
| 628 | CVS-like way.</p> |
| 629 | <p>For some interesting examples of git use, see the |
| 630 | <a href="howto-index.html">howtos</a>.</p> |
| 631 | <p>For git developers, the <a href="core-tutorial.html">Core tutorial</a> goes |
| 632 | into detail on the lower-level git mechanisms involved in, for |
| 633 | example, creating a new commit.</p> |
| 634 | </div> |
| 635 | <div id="footer"> |
| 636 | <div id="footer-text"> |
| Junio C Hamano | bb8fb05 | 2006-05-30 07:21:12 | [diff] [blame^] | 637 | Last updated 30-May-2006 07:20:51 UTC |
| Junio C Hamano | 6f8a790 | 2006-05-22 01:10:13 | [diff] [blame] | 638 | </div> |
| 639 | </div> |
| 640 | </body> |
| 641 | </html> |
